State the need for remote method invocation?
The RMI (Remote Method Invocation) is an API that provides a mechanism to create a distributed application in java. The RMI allows an object to invoke methods on an object running in another JVM.
What is service-oriented architecture?
State the difference between XML and XML DTD.
- XML schemas are written in XML while DTD are derived from SGML syntax.
- XML schemas define data types for elements and attributes while DTD doesn't support datatypes.
- XML schemas allow support for namespaces while DTD does not.
- XML schemas define the number and order of child elements, while DTD does not.
- XML schemas can be manipulated on your own with XML DOM but it is not possible in the case of DTD.
- Using XML schema user needs not to learn a new language but working with DTD is difficult for a user.
- XML schema provides secure data communication i.e sender can describe the data in a way that the receiver will understand but in the case of DTD data can be misunderstood by the receiver.
- XML schemas are extensible while DTD is not extensible
Define middleware with the help of an example.
Middleware software is specially designed for operating systems to link two separate applications together. Middleware offers to message features that enable different applications to communicate by utilizing messaging frameworks like(TYPES) SOAP, JSON, Web services, and REST. Common middleware examples include database middleware, application server middleware, message-oriented middleware, web middleware, and transaction-processing monitors.
Long Question
What Is CORBA Explain with Diagrammatic Illustration the Building Blocks of CORBA Architecture?
The Common Object Request Broker Architecture (CORBA) is a standard developed by the Object Management Group (OMG) to provide interoperability among distributed objects. CORBA is the world's leading middleware solution enabling the exchange of information, independent of hardware platforms, programming languages, and operating systems.
CORBA is essentially a design specification for an Object Request Broker (ORB), where an ORB provides the mechanism required for distributed objects to communicate with one another, whether locally or on remote devices, written in different languages, or at different locations on a network.
The CORBA Interface Definition Language, or IDL, allows the development of language and location-independent interfaces to distributed objects. Using CORBA, application components can communicate with one another no matter where they are located, or who has designed them. CORBAprovides the location transparency to be able to execute these applications.
CORBA is often described as a "software bus" because it is a softwarebased communications interface through which objects are located and accessed. The illustration below identifies the primary components seen within a CORBA implementation.
Data communication from client to server is accomplished through a well-defined object-oriented interface. The Object Request Broker (ORB) determines the location of the target object, sends a request to that object, and returns any response back to the caller. Through this object-oriented technology, developers can take advantage of features such as inheritance, encapsulation, polymorphism, and runtime dynamic binding.
Interface Definition Language (IDL)
A cornerstone of the CORBA standards is the Interface Definition Language. IDL is the OMG standard for defining language-neutral APIs and provides the platform-independent delineation of the interfaces of distributed objects. The ability of the CORBA environments to provide consistency between clients and servers in heterogeneous environments begins with a standardized definition of the data and operations constituting the client/server interface. This standardization mechanism is the IDL, and is used by CORBA to describe the interfaces of objects.
IDL defines the modules, interfaces, and operations for the applications and is not considered a programming language. The various programming languages, such as Ada, C++, C#, or Java, supply the implementation of the interface via standardized IDL mappings.
Application Development Using ORBexpress
The basic steps for CORBA development can be seen in the illustration below. This illustration provides an overview of how the IDL is translated to the corresponding language (in this example, C++), mapped to the source code, compiled, and then linked with the ORB library, resulting in the client and server implementation.
The basic steps for CORBA development include:
The IDL provides the operating system and programming language independent interfaces to all services and components that are linked to the ORB. The IDL specifies a description of any services a server component exposes to the client. The term "IDL Compiler" is often used, but the IDL is actually translated into a programming language.
Translate the IDL
An IDL translator typically generates two cooperative parts for the client and server implementation, stub code and skeleton code. The stub code generated for the interface classes is associated with a client application and provides the user with a well-defined Application Programming Interface (API). In this example, the IDL is translated into C++.
Compile the Interface Files
Once the IDL is translated into the appropriate language, C++ in this example, these interface files are compiled and prepared for the object implementation.
Complete the Implementation
If the implementation classes are incomplete, the spec and header files and complete bodies and definitions need to be modified before passing through to be compiled. The output is a complete client/server implementation.
Compile the Implementation
Once the implementation class is complete, the client interfaces are ready to be used in the client application and can be immediately incorporated into the client process. This client process is responsible for obtaining an object reference to a specific object, allowing the client to make requests to that object in the form of a method call on its generated API.
Link the Application
Once all the object code from steps three and five have been compiled, the object implementation classes need to be linked to the C++ linker. Once linked to the ORB library, in this example, ORBexpress, two executable operations are created, one for the client and one for the server.
Run the Client and Server
The development process is now complete and the client will now communicate with the server. The server uses the object implementation classes allowing it to communicate with the objects created by the client requests.
- Create the required objects.
- Notify the CORBA environment that it is ready to receive client requests.
- Process client requests by dispatching the appropriate servant.
Implement a simple network client and server communication in java using TCP sockets.
Java Socket programming is used for communication between the applications running on different JRE.Java Socket programming can be connection-oriented or connection-less.Socket and ServerSocket classes are used for connection-oriented socket programming and DatagramSocket and DatagramPacket classes are used for connection-less socket programming.The client in socket programming must know two information:
- IP Address of Server, and
- Port number.
Here, we are going to make one-way client and server communication. In this application, the client sends a message to the server, the server reads the message and prints it. Here, two classes are being used: Socket and ServerSocket. The Socket class is used to communicate client and server. Through this class, we can read and write messages. The ServerSocket class is used at the server-side. The accept() method of ServerSocket class blocks the console until the client is connected. After the successful connection of the client, it returns the instance of Socket at the server-side.
Socket class
A socket is simply an endpoint for communications between the machines. The Socket class can be used to create a socket.
ServerSocket class
The ServerSocket class can be used to create a server socket. This object is used to establish communication with the clients.
Example of Java Socket ProgrammingCreating Server:
To create the server application, we need to create the instance of ServerSocket class. Here, we are using the 6666 port number for the communication between the client and server. You may also choose any other port number. The accept() method waits for the client. If the client connects with the given port number, it returns an instance of Socket.
- ServerSocket ss=new ServerSocket(6666);
- Socket s=ss.accept();//establishes connection and waits for the client
Creating Client:
To create the client application, we need to create the instance of the Socket class. Here, we need to pass the IP address or hostname of the Server and a port number. Here, we are using "localhost" because our server is running on the same system.
- Socket s=new Socket("localhost",6666);
Let's see a simple Java socket programming where the client sends a text and the server receives and prints it.
- import java.io.*;
- import java.net.*;
- public class MyServer {
- public static void main(String[] args){
- try{
- ServerSocket ss=new ServerSocket(6666);
- Socket s=ss.accept();//establishes connection
- DataInputStream dis=new DataInputStream(s.getInputStream());
- String str=(String)dis.readUTF();
- System.out.println("message= "+str);
- ss.close();
- }catch(Exception e){System.out.println(e);}
- }
- }
File: MyClient.java
- import java.io.*;
- import java.net.*;
- public class MyClient {
- public static void main(String[] args) {
- try{
- Socket s=new Socket("localhost",6666);
- DataOutputStream dout=new DataOutputStream(s.getOutputStream());
- dout.writeUTF("Hello Server");
- dout.flush();
- dout.close();
- s.close();
- }catch(Exception e){System.out.println(e);}
- }
- }
To execute this program open two command prompts and execute each program at each command prompt as displayed in the below figure.After running the client application, a message will be displayed on the server console.
Example of Java Socket Programming (Read-Write both sides)
In this example, the client will write first to the server then the server will receive and print the text. Then the server will write to the client and the client will receive and print the text. The step goes on.
File: MyServer.java
- import java.net.*;
- import java.io.*;
- class MyServer{
- public static void main(String args[])throws Exception{
- ServerSocket ss=new ServerSocket(3333);
- Socket s=ss.accept();
- DataInputStream din=new DataInputStream(s.getInputStream());
- DataOutputStream dout=new DataOutputStream(s.getOutputStream());
- BufferedReader br=new BufferedReader(new InputStreamReader(System.in));
- String str="",str2="";
- while(!str.equals("stop")){
- str=din.readUTF();
- System.out.println("client says: "+str);
- str2=br.readLine();
- dout.writeUTF(str2);
- dout.flush();
- }
- din.close();
- s.close();
- ss.close();
- }}
File: MyClient.java
- import java.net.*;
- import java.io.*;
- class MyClient{
- public static void main(String args[])throws Exception{
- Socket s=new Socket("localhost",3333);
- DataInputStream din=new DataInputStream(s.getInputStream());
- DataOutputStream dout=new DataOutputStream(s.getOutputStream());
- BufferedReader br=new BufferedReader(new InputStreamReader(System.in));
- String str="",str2="";
- while(!str.equals("stop")){
- str=br.readLine();
- dout.writeUTF(str);
- dout.flush();
- str2=din.readUTF();
- System.out.println("Server says: "+str2);
- }
- dout.close();
- s.close();
- }}
List and discuss the step involved in building an application using enterprise java bean technology
Building and deploying EJBs in the WebLogic Enterprise environment requires careful planning to define how to locate these EJBs in the WLE distributed environment.
After the Bean Provider has implemented an EJB's business logic and has produced an initial deployment descriptor, the process for building and deploying that EJB in the WLE environment includes the following steps:
➢ Step 1: Obtain the EJB JAR file from the bean provider.➢ Step 2: Modify the deployment descriptor.➢ Step 3: Create the WebLogic EJB extensions to the deployment descriptor DTD.➢ Step 4: Produce the deployable EJB JAR file.➢ Step 5: Configure the EJB application.➢ Step 6: Specify the module initializer object in the WebLogic EJB extensions to the deployment descriptor DTD.
When you build the EJB that has been produced by the Bean Provider, the end result is an EJB JAR file. The WLE system allows you to build two kinds of EJB JAR files:
The remainder of this topic discusses each of these steps in detail.Steps for Building and Deploying EJBsThis section describes the steps for building and deploying EJBs in the WLE environment and also provides the following sections:
- Scaling an EJB Application
- For More Information
Step 1: Obtain the EJB JAR file from the bean provider.
The first step in deploying an EJB is to obtain the EJB JAR file from the Bean Provider. In addition to the class files contained in the EJB JAR file, the EJB JAR file also has a deployment descriptor for each bean in that file. The steps for producing the Bean Provider's EJB JAR file are described in the section Development Steps.
Because multiple EJBs can be joined together in a single, deployable unit, part of the assembly process is joining the EJB JAR files for each of the beans.
Step 2: Modify the deployment descriptor.
As stated in Designing and Developing Enterprise JavaBeans for the WLE System, the deployment descriptor ties together the different classes and interfaces and is used to build the code-generated class files. It also allows you to specify some aspects of the EJB's deployment at run time.
The Bean Provider specifies some initial deployment information in the deployment descriptor. The deployer typically needs to add to or modify that information, such as shown in the following table:
To modify a deployment descriptor, you can use either of the following two methods:
- The WebLogic EJB Deployer
- The manual modification of the deployment descriptor in a text editor
The type of deployment descriptor you produce depends on whether you are creating a standard EJB JAR file or a deployable EJB JAR file.
Creating a Standard EJB JAR File
If you are creating a standard EJB JAR file, you only need to modify the single deployment descriptor contained in the EJB JAR file produced by the Bean Provider. When modifying this deployment descriptor, use the syntax described in the EJB 1.1 Specification produced by Sun Microsystems, Inc.
If you are creating a standard EJB JAR file:
- Make the appropriate modifications to the bean's deployment descriptor file.
- Run the ejbc command, specifying the -nodeploy option.
For more information about the ejbc command, see the Command Reference in the WebLogic Enterprise online documentation.
Creating a Deployable EJB JAR File
If you are creating a deployable EJB JAR file, you need to do the following:
Modify the deployment descriptor, as described in the section Creating a Standard EJB JAR File.Create a WebLogic Enterprise extended deployment descriptor file, which is also created as an XML file, and which specifies the information described in section
Step 3: Create the WebLogic EJB extensions to the deployment descriptor DTD.
For an EJB application to be deployable in the WLE environment, you need to create a file containing the WebLogic EJB extensions to the deployment descriptor DTD. This file specifies the following run time and configuration information for the EJB application:
- Custom application startup and shutdown properties
- Registration of the application's home interfaces
- Persistence information
Specifying the WebLogic EJB Extensions DTD
The file that includes the WebLogic EJB extensions to the deployment descriptor DTD must specify the following DTD reference at the beginning:
<!DOCTYPE Weblogic-ejb-extensions SYSTEM "Weblogic-ejbextensions.dtd" >Specifying the Module Initializer ClassServer application startup and shutdown can be handled automatically by the EJB container. However, if you have special server initialization or shutdown requirements, use the module-initializer-class-name element in the WebLogic EJB extensions to the deployment descriptor DTD to specify the name of the module initializer object.
Step 4: Produce the deployable EJB JAR file.
In this step, you package the deployment descriptor, the compiled files for the EJB classes, the WLE extensions to the deployment descriptor DTD, and any additional required classes into a deployable EJB JAR file. You can do this using the ejbc command, as in the following example:
java com.beasys.ejb.utils.ejbc -validate -i DDfile -x WLEXfile archive-file
The ejbc command performs the following steps:
- Parses the standard EJB deployment descriptor and WebLogic Enterprise extended deployment descriptor XML files, which are represented, respectively, as DDfile and WLEXfile in the preceding
- command.
- Checks the deployment descriptors for semantic consistency, and writes any inconsistencies to standard output.
- Generates the wrapper Java classes and compiles them. This is performed for each EJB in the deployment descriptor.
- Packages the XML deployment descriptors and the generated class files into a deployable EJB JAR file. The command-line argument archive-files specifies the files that are archived into the EJB JAR file.
If you have multiple bean packages meant to be assembled as a deployable unit, the bean packages must be specified in a single deployment descriptor. For more information about the ejbc command, see the Command Reference in the WebLogic Enterprise online documentation.
Step 5: Configure the EJB application.
In the SERVERS section of the UBBCONFIG file, the administrator uses the MODULES keyword to identify the deployed EJB JAR files. Optionally, a related set of startup arguments can be specified for each EJB JAR file. For information about configuring the EJB container, configuring the WLE EJB server process, and specifying values in the UBBCONFIG file, see Creating a Configuration File in the WebLogic Enterprise online documentation.
Step 6: Specify the module initializer object in the WebLogic EJB
extensions to the deployment descriptor DTD.Server application startup and shutdown can be handled automatically by the EJB container. However, if you have special server initialization or shutdown requirements, you need to implement an application entity called the module initializer object.The module initializer object implements operations that execute the following tasks:
- Performing basic module initialization (or EJB JAR file deployment) operations, which may include allocating resources needed by the EJB JAR file.
- Performing basic server application initialization operations, which may include registering homes or factories managed by the server application and allocating resources needed by the server application.
- Performing server process shutdown and cleanup procedures when the server application has finished servicing requests.
Note: For EJBs, the scope of the module initializer object is at the EJB JAR file level and not of the entire server application, as with the Server object and WLE CORBA applications.You implement this module initializer object by creating a module initializer class that derives from com.beasys.Tobj.Server and by implementing the following two methods in that class:
initialize
The initialize method is invoked when the EJB JAR file loaded (generally when the WLE server process is booted).
release
The release method is invoked when the WLE server process is shut down or when the EJB JAR file is redeployed to another server process.In the module initializer object application code, you can also write a public default constructor. You create the module initializer object class from scratch using a text editor